暂无会话历史记录哦～
W3C推荐标准 2022年3月3日
参见 翻译.
Copyright © 2022 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
凭证是我们日常生活的一部分：驾驶证用来证明我们有能力驾驶机动车，大学学位证被用来证明我们的受教育程度，政府签发的护照让我们能够在不同国家之间旅行。本规范提供了一种机制，可以在Web上以加密安全、隐私保护和机器可验证的方式表达这些凭证。
状态更新（2025年6月）：此版本已过时！最新版本请参阅https://www.w3.org/TR/vc-data-model/.
本节描述了本文档发布时的状态。当前W3C发布的文档列表和本技术报告的最新版本可在W3C技术报告索引(https://www.w3.org/TR/) 中找到。
欢迎随时对本规范提出意见，但读者应注意，针对此特定版本文档的意见征询期已结束，工作组在此阶段不会对此版本规范进行实质性修改。请直接在GitHub上提交问题，或发送至public-vc-comments@w3.org（订阅，存档）。
工作组已收到实施反馈，表明规范中的每个规范性功能至少有两个实现。该工作组已获得十四(14)个实施的报告。有关详细信息，请参阅测试套件和实施报告。
本文档由可验证凭证工作组作为推荐标准在推荐轨道上发布。
W3C建议将本规范广泛部署为Web标准。
W3C推荐标准是指经过广泛协商一致后，由W3C及其成员认可的规范，并且工作组成员承诺对实现进行免版税许可。
本文档由遵循W3CW3C专利政策的工作组制定。W3C维护着一份与该工作组交付成果相关的任何专利披露的公开列表；该页面还包含披露专利的说明。知悉某项专利包含基本权利要求的个人必须根据W3C专利政策第6节披露该信息。
本文档受2021年11月2日W3C流程文档的约束。
本章节不包含规范性内容。
凭证是我们日常生活的一部分；驾驶执照用于证明我们有能力驾驶机动车，大学学位可以用于证明我们的教育水平，政府签发的护照使我们能够在国家之间旅行。这些凭证在现实世界中使用时会给我们带来好处，但它们在网络上的使用仍然充满挑战。
目前，在网络上表达教育资格、医疗数据、金融账户信息以及其他类型的经第三方验证的机器可读个人信息仍然较为困难。由于难以在网络上表达数字凭证，导致我们难以通过网络获得与在现实世界中使用实体凭证相同的好处。
本标准提供了一种在网络上以加密安全、尊重隐私且机器可验证的方式表达凭证的标准方法。
对于不熟悉可验证凭证相关概念的读者，以下章节提供了概述：
在现实世界中，凭证可能包含以下信息：
可验证凭证可以表示与实体凭证相同的所有信息。数字签名等技术的加入使得可验证凭证比其对应的实体凭证更具防篡改性和可信度。
可验证凭证的持有者可以生成可验证展示，然后与验证者共享这些可验证展示，以证明他们拥有具有某些特征的可验证凭证。
可验证凭证和可验证展示都可以快速传输，这使得它们在试图建立远程信任时比其对应的实体凭证更加便捷。
虽然本规范试图提高表达数字凭证的便捷性，但它也试图将这一目标与一系列隐私保护目标相平衡。数字信息的持久性以及轻松收集和关联不同来源的数字数据的便捷性构成了一个隐私问题，使用可验证且易于机器读取的凭证可能会加剧这一问题。本文档在7.隐私注意事项中概述并试图解决其中的一些问题。本文档还提供了关于如何使用增强隐私技术的示例，例如零知识证明。
可验证凭证和可验证展示中的“可验证”一词指的是凭证或展示能够被验证者验证的特性，如本文档中所定义。凭证的可验证性并不意味着其中编码的声明的真实性可以被评估；但是，签发者可以在evidence属性中包含值，以帮助验证者应用其业务逻辑来确定声明是否具有满足其需求的真实性。
本节描述了在可验证凭证预计有用的生态系统中核心参与者的角色及其之间的关系。角色是一种可以通过多种不同方式实现的抽象概念。角色的分离表明了可能需要标准化的接口和协议。本规范介绍了以下角色：
图1提供了一个示例生态系统，用以阐释本规范中的其他概念。还存在其他生态系统，例如受保护的环境或专有系统，在这些环境中，可验证凭证也能发挥作用。
可验证凭证用例文档[VC-USE-CASES]概述了一些读者可能会觉得有用的关键主题，包括：
在记录和分析用例文档后，针对本规范确定了以下生态系统的理想特征：
除了标记为非规范性的部分外，本规范中的所有创作指南、图表、示例和注释均为非规范性的。本规范中的所有其他内容均为规范性的。
本文档中的关键词可以、必须、禁止、建议和应该在且仅当它们以全部大写字母出现（本文斜体表示）时，才应按照BCP 14[RFC2119] [RFC8174]中的描述进行解释，如此处所示。
符合规范的文档是符合本规范中规范性声明的数据模型的任何具体表达。具体来说，本文档第4.基本概念、5.高级概念和6.语法中的所有相关规范性声明必须 强制执行。符合规范的文档的序列化格式 必须 如第6.语法中所述，是确定性的、双向的和无损的。符合规范的文档可以 以任何此类序列化格式传输或存储。
符合规范的处理器是以软件和/或硬件实现的任何算法，用于生成或使用符合规范的文档。当使用不符合规范的文档时，符合规范的处理器必须 产生错误。
本规范不对生态系统中角色（例如签发者、持有者或验证者）的一致性做出规范性声明，因为生态系统角色的一致性高度依赖于应用程序、用例和垂直市场。
需要数字证明机制（其中一部分是数字签名）来确保可验证凭证的保护。拥有和验证证明（这可能取决于证明的语法，例如，使用JSON Web Token的JSON Web签名来证明密钥持有者）是处理可验证凭证的重要组成部分。在发布时，工作组成员已使用至少三种证明机制实现了可验证凭证：
建议实施者注意，并非所有证明机制在本规范发布之日都已标准化。该工作组预计其中一些机制以及新的机制将独立成熟并及时实现标准化。鉴于存在多种有效的证明机制，本规范并未对任何单一数字签名机制进行标准化。本规范的目标之一是提供一个可以被各种当前和未来数字证明机制保护的数据模型。符合本规范并不取决于特定证明机制的细节；它需要清楚地识别可验证凭证使用的机制。
本文档还包含 JSON 和 JSON-LD 内容的示例。其中一些示例包含无效的 JSON 字符，例如内联注释 (//) 和使用省略号 (...)来表示对示例价值不大的信息。如果实施者希望将信息用作有效的 JSON 或 JSON-LD，则应注意删除此内容。
//
...
以下术语用于描述本规范中的概念。
did:example:123456abcdef
以下章节概述了核心数据模型的概念，例如声明、凭证和展示，这些概念构成了本规范的基础。
声明是对主体做出的声明。主体是可以对其进行声明的事物。声明使用主体-属性-值关系来表达。
声明的数据模型（如上面图2所示）功能强大，可以用来表达各种各样的声明。例如，某人是否从某所大学毕业可以用下图3所示的方式来表达。
多个单独的声明可以合并在一起，以表达关于某个主体的信息图。下图4所示的示例通过添加“Pat 认识 Sam”和“Sam 受聘为教授”这两个声明扩展了之前的声明。
至此，我们介绍了声明和信息图的概念。为了能够信任声明，我们需要向图中添加更多信息。
凭证是由同一实体发出的一组或多组声明。凭证还可以包含标识符和元数据，用于描述凭证的属性，例如签发者、到期日期和时间、代表性图像、用于验证的公钥、撤销机制等等。元数据可由签发者签名。可验证凭证是一组防篡改的声明和元数据，可以通过密码学方法证明其签发者。
可验证凭证的例子包括数字员工证、数字出生证明和数字教育证书。
凭证标识符通常用于标识凭证的特定实例。这些标识符也可以用于关联。如果持有者希望尽量减少关联性，建议使用不透露凭证标识符的选择性披露方案。
上面的图5展示了可验证凭证的基本组成部分，但抽象化了声明如何组织成信息图，以及信息图如何组织成可验证凭证的细节。下面的图6展示了可验证凭证的更完整描述，它通常由至少两个信息图组成。第一个信息图表示可验证凭证本身，其中包含凭证元数据和声明。第二个信息图表示数字证明，通常是数字签名。
有些凭证（例如结婚证）可能包含关于不同主体的多个声明，这些主体之间不需要是相关的。
有些凭证可能不包含关于凭证签发对象的任何声明。例如，一个凭证可能只包含关于某只特定狗的声明，但却签发给它的主人。
增强隐私性是本规范的一个关键设计特性。因此，对于使用此技术的实体而言，能够仅表达与其特定情境相符的部分身份信息至关重要。这种对自身身份信息子集的表达被称为可验证展示。不同身份信息的示例包括个人的职业身份、网络游戏身份、家庭身份或匿名身份。
可验证展示表达了一个或多个可验证凭证中的数据，并以一种可以验证数据作者身份的方式进行打包。如果直接展示可验证凭证，则它们本身就成为可验证展示。从可验证凭证派生出的数据格式，即使自身不包含可验证凭证，但如果可进行密码学验证，也可能构成可验证展示。
展示中的数据通常是关于同一主体的，但可能由多个签发者签发。这些信息的聚合通常表达了一个人、组织或实体的某个方面。
上面的图7展示了可验证展示的组成部分，但抽象化了可验证凭证如何组织成信息图，以及信息图如何组织成可验证展示的细节。
下面的图8更完整地描绘了可验证展示，它通常由至少四个信息图组成。第一个信息图，即展示图，表达了可验证展示本身，其中包含展示元数据。展示图中的verifiableCredential属性引用了一个或多个可验证凭证，每个凭证都是信息图（第二个信息图），即一个自包含的凭证图，其中包含凭证元数据和声明。第三个信息图，即凭证证明图，表达了凭证图的证明，通常是数字签名。第四个信息图，即展示证明图，表达了展示图的证明，通常也是数字签名。
verifiableCredential
可以编写一个展示文档，例如商业角色，可以利用关于不同主体的多个凭证，这些主体通常是相关的，但不要求必须相关。
前面的章节使用图形介绍了声明、可验证凭证和可验证展示的概念。本节提供了一组具体的、简单但完整的生命周期示例，这些示例以本规范支持的其中一种具体语法表达了数据模型。可验证凭证生态系统中凭证和展示的生命周期通常遵循一个共同的路径：
为了说明此生命周期，我们将使用一个从大学兑换校友折扣的示例。在下面的示例中，Pat从大学收到了一个校友可验证凭证，并将该可验证凭证存储在数字钱包中。
随后，Pat 尝试兑换校友折扣。验证者，即票务销售系统，声明“示例大学”的任何校友都可以获得体育赛事季票的折扣。Pat 使用移动设备开始购买季票。此流程中的一个步骤请求提供校友可验证凭证，该请求被路由到Pat的数字钱包。数字钱包询问 Pat 是否愿意提供先前签发的可验证凭证。Pat 选择了校友可验证凭证，然后将其组合成可验证展示。可验证展示被发送给验证者并进行验证。
有意深入了解上述证明机制的实施者，可以参考第 4.7证明（签名）节以及以下规范：数据完整性 [DATA-INTEGRITY]、链接数据加密套件注册表 [LDP-REGISTRY] 和 JSON Web 签名 (JWS) 未编码载荷选项[RFC7797]。可验证凭证扩展注册表 [VC-EXTENSION-REGISTRY] 中提供了证明机制列表。
本节介绍规范的一些基本概念，为文档后面的5.高级概念做准备。
当两个软件系统需要交换数据时，它们需要使用双方都能理解的术语。 举个例子，想想两个人是如何交流的。双方必须使用相同的语言，并且他们使用的词语对彼此来说必须具有相同的含义。这可以被称为对话的上下文。
可验证凭证和可验证展示具有许多由URI[RFC3986]标识的属性和值。但是，这些URI可能很长，而且对用户不太友好。在这种情况下，简短易懂的别名会更有帮助。本规范使用@context属性将此类简短别名映射到特定可验证凭证和可验证展示所需的URI。
@context
在JSON-LD中，@context属性还可以用于传递其他详细信息，例如数据类型信息、语言信息、转换规则等，这些信息超出了本规范的需求，但在将来或相关工作中可能会有用。有关详细信息，请参阅[JSON-LD]规范的第3.1 节“上下文”。
可验证凭证和可验证展示必须包含@context属性。
https://www.w3.org/2018/credentials/v1M
尽管本规范要求存在 @context 属性，但并不要求使用 JSON-LD 去处理 @context 属性的值。这是为了支持使用普通 JSON 库进行处理，例如在可验证凭证被编码为 JWT 时可能使用的库。所有库或处理器必须确保 @context 属性中值的顺序符合特定应用程序的预期。支持 JSON-LD 的库或处理器可以使用完整的 JSON-LD 处理来处理 @context 属性，如预期的那样。
上述示例使用了基础上下文URI (//www.w3.org/2018/credentials/v1) 来确定对话是关于可验证凭证的。第二个 URI (https://www.w3.org/2018/credentials/examples/v1) 用于表明对话是关于示例的。
//www.w3.org/2018/credentials/v1
https://www.w3.org/2018/credentials/examples/v1
本文档使用示例上下文URI (//www.w3.org/2018/credentials/examples/v1) 来演示示例。实施者不应将此URI用于任何其他目的，例如在试点或生产系统中。
//www.w3.org/2018/credentials/examples/v1
https://www.w3.org/2018/credentials/v1
当我们需要描述特定事物（例如个人、产品或组织）的相关信息时，使用某种标识符以便他人也能针对同一事物进行描述，是非常有用的。本规范定义了用于此类标识符的可选id属性。id属性旨在明确地指代一个对象，例如一个人、一个产品或一个组织。使用id属性可以在可验证凭证中陈述特定事物。
id
如果存在id属性：
开发者应牢记，在需要匿名性的场景中，标识符可能会带来风险。开发者在考虑此类场景时，建议仔细阅读7.3基于标识符的相关性。此外，7.隐私考量中还记录了其他类型的关联机制，这些机制也会引发隐私问题。在高度重视隐私的情况下，可以省略id属性。
上述示例使用了两种类型的标识符。第一种标识符用于可验证凭证，采用基于HTTP的URL。第二种标识符用于可验证凭证的主体（即声明所描述的对象），采用去中心化标识符，也称为DID。
截至本文发布之时，DID是一种新型标识符，并非可验证凭证发挥效用所必需的。具体而言，可验证凭证不依赖于DID，DID也不依赖于可验证凭证。然而，预计许多可验证凭证将会使用DID，并且实现本规范的软件库很可能需要解析DID。基于DID的URL用于表达与主体、签发者、持有者、凭证状态列表、加密密钥以及与可验证凭证相关的其他机器可读信息相关的标识符。
处理本文档中指定类型的对象的软件系统使用类型信息来确定所提供的可验证凭证或可验证展示是否合适。本规范定义了一个用于表达类型信息的type属性。
type
可验证凭证和可验证展示必须包含type属性。也就是说，任何不包含type属性的凭证或展示都不可验证，因此这些凭证不是可验证凭证，这些展示也不是可验证展示。
关于本规范，下表列出了必须指定类型的对象。
VerifiableCredential
CredentialManagerPresentation
"type": "RsaSignature2018"
"type": "CredentialStatusList2017"
"type": "OdrlPolicy2017"
"type": "DocumentVerification2018"
可验证凭证数据模型的类型系统与[JSON-LD]相同，详见其5.4:指定类型。当使用JSON-LD上下文时（参见5.3可扩展性），本规范将@type关键字别名为type，以便JSON-LD文档更易于理解。虽然应用程序开发者和文档作者无需了解JSON-LD类型系统的细节，但希望支持互操作性扩展的本规范实现者则需要了解。
所有凭证、展示文稿和封装对象必须指定或关联其他更具体的类型（例如 UniversityDegreeCredential），以便软件系统可以处理这些附加信息。
在处理本规范中定义的封装对象时（例如，与 credentialSubject 对象关联或深度嵌套在其中的对象），软件系统应该使用封装对象在层次结构中更高层次对象中指定的类型信息。具体来说，封装对象（例如凭证）应该传达关联对象的类型，以便验证者可以根据封装对象的类型快速确定关联对象的内容。
例如，类型为UniversityDegreeCredential的凭证对象向验证者表明，与credentialSubject属性关联的对象包含以下标识符：
这使得实现者可以依赖与type属性关联的值进行验证。对类型及其关联属性的预期应至少记录在人类可读的规范中，最好还记录在其他机器可读的表示形式中。
本规范中描述的数据模型中使用的类型系统允许多种方式将类型与数据关联。强烈建议实现者和作者阅读可验证凭证实施指南[VC-IMP-GUIDE]中关于类型的章节。
可验证凭证包含关于一个或多个主体的声明。本规范定义了一个credentialSubject属性，用于表达关于一个或多个主体的声明。
可验证凭证必须包含credentialSubject属性。
可以在可验证凭证中表达与多个主体相关的信息。下面的示例指定了两个作为配偶的主体。请注意，这里使用了数组表示法将多个主体与credentialSubject属性关联。
本规范定义了一个用于表达可验证凭证的签发者的属性。
可验证凭证必须包含issuer属性。
还可以通过将一个对象与issuer属性关联来表达关于签发者的其他信息：
issuer属性的值也可以是JWK（例如，“https://example.com/keys/foo.jwk”）或DID（例如，“did:example:abfe13f712120431c276e12ecab”）。
本规范定义了issuanceDate属性，用于表达凭证生效的日期和时间。
预计下一版规范将添加validFrom属性，并弃用issuanceDate属性，转而使用新的issued属性。这两个属性的值范围预计仍将是[XMLSCHEMA11-2]中定义的组合日期时间字符串。建议开发者注意validFrom和issued属性已被保留，不建议将其用于任何其他用途。
为了使凭证或展示成为可验证凭证或可验证展示，即能够被验证，必须表达至少一种证明机制以及评估该证明所需的详细信息。
本规范确定了两类证明机制：外部证明和嵌入式证明。外部证明是对这种数据模型的表达式的包装，例如JSON Web Token，这将在6.3.1节 “JSON Web Token” 中详细阐述。嵌入式证明是一种将证明包含在数据中的机制，例如链接数据签名，这将在6.3.2节“数据完整性证明”中详细阐述。
当嵌入证明时，必须使用proof属性。
由于数学证明所使用的方法因表示语言和所用技术而异，因此proof属性的值预计包含的名称-值对集也将相应变化。例如，如果使用数字签名作为证明机制，则proof属性应包含名称-值对，其中包括签名、对签名实体的引用以及签名日期的表示形式。下面的示例使用RSA数字签名。
如1.4节“一致性”中所述，存在多种可行的证明机制，本规范并未标准化或推荐任何单一证明机制用于可验证凭证。有关证明机制的更多信息，请参阅以下规范：数据完整性[DATA-INTEGRITY]、链接数据密码套件注册表[LDP-REGISTRY]和JSON Web签名(JWS)未编码有效负载选项[RFC7797]。可验证凭证扩展注册表[VC-EXTENSION-REGISTRY]中提供了一份证明机制列表。
本规范定义了expirationDate属性，用于表示凭证过期信息。
预计下一版规范将添加validUntil属性，该属性将弃用expirationDate属性，但会保留与之的向后兼容性。建议实施者注意，validUntil属性已被保留，不建议将其用于任何其他目的。
本规范定义了以下credentialStatus属性，用于发现有关可验证凭证当前状态的信息，例如是否已暂停或撤销。
凭证状态信息的精确内容由特定的credentialStatus类型定义确定，并且会因为各种因素的不同（例如其实现是否简单或是否增强隐私性）而有所差异。
定义状态方案的数据模型、格式和协议超出了本规范的范围。可验证凭证扩展注册表[VC-EXTENSION-REGISTRY]中包含了可用状态方案，可供希望实现可验证凭证状态检查的实施者使用。
展示可以用于组合和呈现凭证。它们可以被打包成一种数据作者身份可验证的方式。展示中的数据通常都与同一个主体相关，但数据中的主体或签发者数量没有限制。聚合来自多个可验证凭证的信息是可验证展示的典型用例。
一个可验证展示通常由以下属性组成：
下面的示例展示了一个嵌入了可验证凭证的可验证展示。
上述的verifiableCredential属性的内容是可验证凭证，如本规范所述。proof属性的内容是证明，如数据完整性[DATA-INTEGRITY]规范所述。第6.3.1节“JSON Web Token”给出了一个使用JWT证明机制的可验证展示示例。
一些零知识密码方案可能允许持有者间接证明他们持有来自可验证凭证的声明，而无需透露可验证凭证本身。在这些方案中，来自可验证凭证的声明可能被用来派生一个展示的值，该值经过密码学声明，使验证者在信任签发者的情况下可以信任该值。
例如，一个包含声明出生日期的可验证凭证可以用来派生“年龄超过15岁”的展示值，该值是可以通过密码学方式验证的。也就是说，如果验证者信任签发者，他们仍然可以信任派生值。
有关包含派生数据而非直接嵌入的可验证凭证的零知识证明风格的可验证展示示例，请参见5.8节“零知识证明”。
使用零知识证明的选择性披露方案可以利用此模型中表达的声明来证明关于这些声明的附加陈述。例如，一个指定主体出生日期的声明可以被用作谓词，以证明主体的年龄在给定范围内，从而证明主体有资格享受与年龄相关的折扣，而无需实际透露主体的出生日期。持有者可以灵活地以任何适用于所需可验证展示的方式使用该声明。
在4. 基本概念的基础上，本章将探讨有关可验证凭证的更复杂主题。
1.2 生态系统概述提供了可验证凭证生态系统的概述。本节将更详细地介绍该生态系统的预期运作方式。
可验证凭证生态系统中的角色和信息流如下：
上述操作的顺序并非固定不变，某些操作可能会执行多次。此类操作的重复执行可以立即进行，也可以在稍后的任何时间点进行。
最常见操作顺序被设想如下：
本规范未定义任何用于传输可验证凭证或可验证展示的协议，但如果其他规范确实指定了它们如何在实体之间传输，那么本可验证凭证数据模型将直接适用。
本规范也未定义授权框架，也未定义验证者在验证可验证凭证或可验证展示后可能做出的决策，包括考虑持有者、可验证凭证的签发者、可验证凭证的内容及其自身策略。
特别是，第 5.6 节“使用条款”和附录 C“主体-持有者关系”规定了验证者如何确定：
可验证凭证的信任模型如下：
这种信任模型区别于其他信任模型的特点在于确保：
通过将身份提供者和依赖方之间的信任解耦，创建了一种更加灵活和动态的信任模型，从而增强了市场竞争和客户选择。
有关此信任模型如何与工作组研究的各种威胁模型交互的更多信息，请参阅可验证凭证用例文档[VC-USE-CASES]。
本规范中详述的数据模型并不是一种传递式信任模型，例如更传统的证书签发机构信任模型所提供的模型。在可验证凭证数据模型中，验证者要么直接信任签发者，要么不信任签发者。虽然可以使用可验证凭证数据模型构建传递性信任模型，但强烈建议实施者了解以证书签发机构系统采用的方式来广泛委托信任的行为所带来的安全隐患。
可验证凭证数据模型的目标之一是实现无需许可的创新。为实现此目标，数据模型需要在许多不同方面具有可扩展性。数据模型必须能够：
这种数据建模方法通常被称为开放世界假设，这意味着任何实体都可以对任何其他实体发表任何言论。虽然这种方法似乎与构建简单且可预测的软件系统相冲突，但在开放世界假设下，平衡可扩展性和程序正确性始终比在封闭软件系统中更具挑战性。
本节的其余部分将通过一系列示例来说明如何实现可扩展性和程序正确性。
让我们假设我们从下面显示的可验证凭证开始。
此可验证凭证声明与did:example:abcdef1234567关联的实体的姓名值为Jane Doe。
did:example:abcdef1234567
Jane Doe
现在让我们假设开发人员想要扩展该可验证凭证，以存储两个额外的信息：一个内部公司参考编号和Jane最喜欢的食物。
首先要做的是创建一个包含两个新术语的 JSON-LD 上下文，如下所示。
创建此JSON-LD上下文后，开发人员将其发布到某个可访问的位置，以便处理可验证凭证的验证者可以访问它。假设上述JSON-LD上下文发布在https://example.com/contexts/mycontext.jsonld，我们可以通过包含上下文并将新的属性和凭证类型添加到可验证凭证中来扩展此示例。
https://example.com/contexts/mycontext.jsonld
此示例展示了如何以无需许可且去中心化的方式扩展可验证凭证数据模型。所示的机制还确保以这种方式创建的可验证凭证提供了一种防止命名空间冲突和语义歧义的机制。
像这样的动态扩展模型确实增加了实现负担。为这种系统编写的软件必须根据应用程序的风险状况来确定是否可以接受带有扩展的可验证凭证。某些应用程序可能只接受某些扩展，而高度安全的环境可能根本不接受任何扩展。这些决定取决于这些应用程序的开发人员，具体来说并不属于本规范的范围。
强烈建议开发人员确保扩展JSON-LD上下文具有高可用性。无法获取上下文的实现将产生错误。确保扩展JSON-LD上下文始终可用的策略包括对上下文使用内容寻址 URL，将上下文文档与实现捆绑在一起，或启用上下文的积极缓存。
建议实施者密切关注本规范中的扩展点，例如第4.7节“证明（签名）”、第4.9节“状态”、第 5.4 节“数据模式”、第5.5节“刷新”、第5.6节“使用条款”和第5.7节“证据”。虽然本规范没有为这些扩展点定义具体的实现，但可验证凭证扩展注册表[VC-EXTENSION-REGISTRY]提供了一个非官方的、精心策划的扩展列表，开发人员可以从这些扩展点使用这些扩展。
本规范确保“普通”JSON和JSON-LD语法在语义上兼容，而无需JSON实现使用JSON-LD处理器。为此，规范对两种语法都施加了以下附加要求：
寻求互操作性的任何实现者都应发布一个人类可读的文档，描述@context属性值的预期顺序。寻求互操作性的JSON-LD实施者应在@context属性指定的URL上发布机器可读的描述（即普通的JSON-LD上下文文档）。
以上要求保证了JSON和JSON-LD之间由@context机制定义的术语的语义互操作性。虽然JSON-LD处理器将使用提供的特定机制并可以验证所有术语是否正确指定，但基于JSON的处理器会隐式接受同一组术语，而无需测试它们是否正确。换句话说，通过使用相同的机制，数据交换发生的上下文在JSON和JSON-LD中都得到了明确说明。对于基于JSON的处理器，这是以轻量级的方式实现的，无需使用JSON-LD处理库。
数据模式在对给定数据集强制执行特定结构时非常有用。本规范至少考虑以下两种类型的数据模式：
重要的是要理解数据模式与@context属性的用途不同，@context属性既不强制执行数据结构或数据语法，也不允许定义到替代表示格式的任意编码。
本规范定义了以下用于表达数据模式的属性，签发者可以在其签发的可验证凭证中包含该属性：
credentialSchema属性提供了一个机会来注释类型定义或将其锁定到词汇表的特定版本。可验证凭证的作者可以使用credentialSchema包含其词汇表的静态版本，该版本锁定到某些内容完整性保护机制。credentialSchema属性还使得可以对凭证执行语法检查，并使用诸如JSON Schema[JSON-SCHEMA-2018]验证之类的验证机制。
在上面的示例中，签发者指定了一个credentialSchema，它指向一个[JSON-SCHEMA-2018]文件，验证者可以使用该文件来确定可验证凭证是否格式规范。
有关JSON Schema[JSON-SCHEMA-2018]或其他可选验证机制的链接信息，请参阅可验证凭证实施指南[VC-IMP-GUIDE]文档。
数据模式还可以用于指定到其他二进制格式的映射，例如用于执行零知识证明的格式。有关将credentialSchema属性与零知识证明一起使用的更多信息，请参阅5.8节“零知识证明”。
在上面的示例中，签发者指定了一个credentialSchema，它指向一种零知识打包二进制数据格式，该格式能够将输入数据转换为一种格式，然后验证者可以使用该格式来确定可验证凭证提供的证明是否有效。
系统能够手动或自动刷新过期的可验证凭证非常有用。有关过期可验证凭证的更多信息，请参阅4.8过期部分。本规范定义了一个refreshService属性，使签发者可以包含指向刷新服务的链接。
如果签发者希望验证者或持有者（或两者）使用刷新服务，则可以将其作为元素包含在可验证凭证中；如果仅供持有者使用，则可以将其包含在可验证展示中。在后一种情况下，持有者可以在创建要与验证者共享的可验证展示之前刷新可验证凭证。在前一种情况下，将刷新服务包含在可验证凭证中，使持有者或验证者都可以执行凭证的未来更新。
刷新服务预计仅在凭证过期或签发者未发布凭证状态信息时使用。建议签发者不要将refreshService属性放在不包含公共信息或其刷新服务未以某种方式受到保护的可验证凭证中。
将refreshService属性放在可验证凭证中以便验证者可以使用它，可能会剥夺持有者的控制权和同意权，并允许将可验证凭证直接颁发给验证者，从而绕过持有者。
在上面的示例中，签发者指定了一个手动刷新服务，可以通过引导持有者或验证者访问https://example.edu/refresh/3732来使用它。
https://example.edu/refresh/3732
使用条款可以被签发者或持有者用于传达可验证凭证或可验证展示发布的条款。签发者将其使用条款置于可验证凭证内。持有者将其使用条款置于可验证展示内。本规范定义了一个termsOfUse属性来表达使用条款信息。
termsOfUse属性的值告诉验证者如果要接受可验证凭证或可验证展示，它需要执行哪些操作（义务）、不允许执行哪些操作（禁止）或允许执行哪些操作（许可）。
需要进一步研究以确定非持有者的主体如何在他们的可验证凭证上放置使用条款。一种方法可能是主体请求签发者将使用条款置于已颁发的可验证凭证内。另一种方法可能是主体将可验证凭证委托给持有者，并在委托的可验证凭证上放置使用条款限制。
在上面的示例中，签发者（转让人）禁止验证者（受让人）将数据存储在档案库中。
警告：termsOfUse属性在可验证展示范围的上下文中定义不正确。这是版本1上下文中的一个错误，将在版本2上下文中修复。与此同时，希望使用此功能的实施者将需要使用定义termsOfUse属性的附加术语扩展其可验证展示的上下文，然后可以将其与可验证展示类型属性一起使用，以便JSON-LD处理器能够在语义上识别该术语。
在上面的示例中，持有者（转让人），同时也是主体，表达了一项使用条款，禁止验证者（受让人，https://wineonline.example.org）使用提供的信息通过第三方服务关联持有者或主体。如果验证者使用第三方服务进行关联，则他们将违反持有者创建展示的条款。
https://wineonline.example.org
预计此功能也将被政府签发的可验证凭证使用，以指示数字钱包将其使用限制在类似的政府组织，试图保护公民免受敏感数据被意外使用。类似地，预计私营行业签发的一些可验证凭证会将其使用限制在组织内部的部门内，或在工作时间内。敦促实施者在可验证凭证实施指南[VC-IMP-GUIDE]文档的相应部分中阅读更多关于此快速发展功能的信息。
签发者可以在可验证凭证中包含证据，以便为验证者提供额外的支持信息。验证者可以使用这些信息来确定其对可验证凭证中声明的信任程度。
例如，签发者可以在签发凭证之前检查主体提供的物理文件或执行一系列背景调查。在某些情况下，当确定依赖于给定凭证的相关风险时，此信息对验证者很有用。
本规范定义了用于表达证据信息的evidence属性。
有关规范如何支持附件以及对凭证和非凭证数据的引用的信息，请参阅可验证凭证实施指南[VC-IMP-GUIDE]文档。
在此证据示例中，签发者声明他们将凭证的主体与所述驾照号码的驾照的物理副本进行了物理匹配。此驾照在签发过程中除了被用于验证“示例大学”在颁发凭证之前验证了主体，还用于展现他们是如何进行验证的（物理验证）。
evidence属性提供与proof属性不同且互补的信息。evidence属性用于表达支持信息，例如与可验证凭证的完整性相关的文件证据。与evidence属性相反，proof属性用于表达与签发者的真实性和可验证凭证的完整性相关的机器可验证的数学证明。有关proof属性的更多信息，请参见第4.7节 证明（签名）。
零知识证明是一种密码学方法，实体可以借此向另一实体证明其知道某个值，而无需披露该值的实际内容。现实世界中的一个例子是证明一所经认可的大学授予了你学位，而无需透露你的身份或学位证书上包含的任何其他个人身份信息。
零知识证明机制引入的关键功能使持有者能够：
本规范描述了一个支持使用零知识证明机制进行选择性披露的数据模型。以下示例重点介绍了如何使用该数据模型来签发、展示和验证零知识可验证凭证。
为了使持有者能够使用零知识可验证展示，他们需要签发者以一种能够使持有者从最初签发的可验证凭证中派生证明的方式签发可验证凭证，以便持有者能够以增强隐私的方式向验证者展示信息。这意味着持有者可以在不透露已签名值的情况下，或仅在透露某些选定值时，证明签发者签名的有效性。标准做法是通过证明对签名的知识来实现，而无需透露签名本身。当可验证凭证要在零知识证明系统中使用时，它们有两个要求。
以下示例展示了在零知识中使用可验证凭证的一种方法。它使用了Camenisch-Lysyanskaya签名[CL-SIGNATURES]，该签名允许以支持持有者和主体隐私的方式展示可验证凭证，方法是选择性地披露可验证凭证的值。其他一些依赖零知识证明来选择性披露属性的密码系统也可以在[LDP-REGISTRY]中找到。
上述示例通过使用credentialSchema属性和Camenisch-Lysyanskaya零知识证明系统中可用的特定证明，提供了可验证凭证的定义。
下一个示例利用上述可验证凭证生成一个带有隐私保护证明的新派生可验证凭证。然后将派生可验证凭证放入可验证展示中，以便于让该可验证凭证仅披露持有者预期的声明和其他凭证元数据。为此，预期满足以下所有要求：
本文档特意省略了有关凭证定义和证明格式的重要细节，因为它们超出了本文档的范围。本节旨在指导希望扩展可验证凭证和可验证展示以支持零知识证明系统的实施者。
体希望对签发者签发的凭证提出异议，至少需要考虑以下两种情况：
发出争议凭证的机制与常规凭证相同，区别在于争议凭证属性中的credentialSubject标识符是被争议凭证的标识符。
例如，如果对标识符为https://example.org/credentials/245的凭证存在争议，主体可以发出如下所示的凭证，并将其与有争议的凭证一起提交给验证者。
https://example.org/credentials/245
在上述可验证凭证中，签发者声称有争议的可验证凭证中的地址是错误的。
如果凭证没有标识符，可以使用内容寻址标识符来识别有争议的凭证。同样，内容寻址标识符也可以用来唯一地标识个体声明。
该研究领域正在快速发展，有意愿发布质疑其他凭证真实性的凭证的开发者，强烈建议阅读可验证凭证实施指南[VC-IMP-GUIDE]文档中与争议相关的部分。
可验证凭证旨在作为一种可靠识别主体身份的方式。尽管基于角色访问控制（RBAC）和基于属性访问控制（ABAC）都依赖于这种身份识别作为授权主体访问资源的手段，但本规范并未提供完整的RBAC或ABAC解决方案。若没有相应的授权框架，本规范不适用于授权用途。
工作组在制定本规范期间确实考虑了授权用例，并正在将其作为构建在本规范之上的架构层进行研究。
3. 核心数据模型、4. 基本概念和5. 高级概念中描述的数据模型是可验证凭证或可验证可验证展示的规范结构表示。所有序列化都是该数据模型在特定格式下的表现形式。本节将具体说明数据模型如何在 JSON-LD 和简单 JSON 中实现。尽管只为这两种语法提供了语法映射，但应用程序和服务可以使用任何其他能够表达数据模型的数据表示语法（例如 XML、YAML 或 CBOR）。由于验证和核验要求是根据数据模型定义的，因此所有序列化语法都必须能够确定性地转换为数据模型，以便进行处理、验证或比较。本规范对任何特定序列化格式的支持均不做要求。
本规范中属性值的预期基数以及存储这些值的结果数据类型可能因属性而异。如果存在，以下属性将表示为单个值：
issuer
issuanceDate
expirationDate
所有其他属性（如果存在）将表示为单个值或值数组。
3. 核心数据模型中所描述的数据模型，可以通过以下方式将属性值映射到 JSON 类型，从而以JavaScript对象表示法（JSON）[RFC8259]进行编码：
由于此处列出的转换可能存在互相矛盾的解释，因此需要对JSON格式进行进一步的分析，以便提供结果为数据模型的确定性转换。
[JSON-LD]是一种基于JSON的格式，用于序列化关联数据。其语法设计旨在轻松融入已部署的、使用 JSON 的系统，并提供从JSON到[JSON-LD]的平滑升级路径。 JSON-LD 主要用于在基于Web的编程环境中使用关联数据，构建可互操作的Web服务，以及在基于JSON的存储引擎中存储关联数据。
在扩展本规范描述的数据模型时，[JSON-LD]非常有用。数据模型的实例与在 JSON（6.1 JSON格式）中编码相同的方式在[JSON-LD]中编码， 并添加了@context属性。JSON-LD上下文在[JSON-LD]规范中有详细描述，其用法在5.3 可扩展性中进行了阐述。
可以使用或组合多个上下文，以便使用惯用的 JSON 来表达关于可验证凭证的任意信息。JSON-LD上下文位于https://www.w3.org/2018/credentials/v1，是一个静态文档，永远不会更新，因此可以下载并缓存在客户端。 可验证凭证数据模型的相关词汇表文档位于https://www.w3.org/2018/credentials。
https://www.w3.org/2018/credentials
总的来说，本文档中描述的数据模型和语法旨在方便实施者能够复制粘贴示例，将可验证凭证集成到他们的软件系统中。这种方法的设计目标是降低入门门槛，同时仍然确保不同软件系统之间的全局互操作性。 本节将介绍其中的一些方法，大多数开发者可能不会注意到这些方法，但其实现细节对于开发者来说却至关重要。[JSON-LD]提供的最值得注意的语法糖包括：
@id
@type
proof
@protected
本规范中描述的数据模型被设计成与证明格式无关的。本规范没有强制要求任何特定的数字证明或签名格式。尽管数据模型是凭证或展示的规范表示形式，但这些证明机制通常与各方之间传输文档时使用的语法相关联。 因此，每种证明机制都必须指定证明的验证是针对传输的文档状态、可能转换后的数据模型还是针对其他形式进行计算。在发布时，至少有两种证明格式被实施者积极使用，工作组认为记录这些证明格式是什么以及它们是如何被使用的将有利于实施者。 详细介绍当前被积极用于签发可验证凭证的证明格式的章节如下：
JSON Web Token (JWT) [RFC7519] 仍然是一种广泛使用的方式，用于在双方之间传递声明。为JWT提供可验证凭证数据模型的表示，允许现有系统和库参与1.2 生态系统概述中描述的生态系统。 JWT 将一组声明编码为 JSON 对象，该对象包含在JSON Web签名(JWS)[RFC7515]或JWE[RFC7516]中。在本规范中，JWE的使用不在讨论范围之内。
本规范定义了可验证凭证数据模型在JWT和JWS上的编码规则。它进一步定义了如何以及何时使用特定的JWT注册声明名称和特定的JWS注册标头参数名称的处理规则，以允许基于 JWT 的系统符合本规范。 如果存在这些特定的声明名称和标头参数，则可以省略标准可验证凭证和可验证展示中相应的部分，以避免重复。
本规范引入了两个新的注册声明名称，它们包含标准可验证凭证和可验证展示中没有明确 JWT 编码规则的部分。这些对象在 JWT 有效负载中按如下方式封装：
vc
vp
为了将可验证凭证编码为 JWT，本规范引入的特定属性必须满足以下条件之一：
如果没有明确的规则，则属性将以与标准凭证相同的方式进行编码，并添加到JWT的vc声明中。 与所有JWT一样，在应用任何解码或转换规则之前，以JWT语法表示的可验证凭证的基于JWS的签名是针对网络上传输的文字JWT字符串值计算的。以下段落描述了这些编码规则。
如果存在 JWS，数字签名指的是可验证凭证的签发者；在可验证展示的情况下，数字签名指的是可验证凭证的持有者。 JWS证明JWT的iss签署了包含的JWT有效负载，因此可以省略proof属性。
iss
如果不存在 JWS，则必须提供proof属性。proof属性可用于表示更复杂的证明，例如当创建者与签发者不同时，或者证明不基于数字签名（例如工作量证明）时，可能需要这样做。 签发者可以同时包含JWS和proof属性。出于向后兼容性的原因，签发者必须使用JWS来表示基于数字签名的证明。
以下规则适用于本规范上下文中的JOSE标头：
alg
none
kid
typ
JWT
为了向后兼容JWT处理器，必须使用以下注册的JWT声明名称来代替或补充其各自的标准可验证凭证对应项：
exp
NumericDate
holder
nbf
jti
sub
credentialSubject
在bearer credentials和presentations中，sub将不存在。
bearer credentials
presentations
aud
文中未明确指出的其他JOSE标头参数和JWT声明名称，只要其使用未被明令禁止，均可使用。其他可验证凭证声明必须添加至JWT的credentialSubject属性中。
有关使用本文档未指定的 JOSE 标头参数和/或 JWT 声明名称的更多信息，请参阅《可验证凭证实施指南》[VC-IMP-GUIDE]。
本规范版本未对高级概念章节中概述的概念（例如，refreshService、termsOfUse和evidence）定义任何JWT特定的编码规则。 这些概念无需任何转换即可按原样编码，并且可以添加到vc JWT声明中。
refreshService
termsOfUse
evidence
实施者需要注意，JSON Web Token(JWT)目前无法编码多个主体，因此无法对包含多个主体的可验证凭证进行编码。 JWT未来可能会支持多个主体，建议开发者参考JSON Web Token声明注册表中关于多主体JWT声明名称的说明，或查阅 嵌套JSON Web Token规范。
要将 JWT 解码为标准的凭证或展示，必须执行以下转换：
要转换JWT特定的头部和声明，必须执行以下操作：
日期时间格式
在上述示例中，可验证凭证采用了基于JWS数字签名的证明方式，相应的核验密钥可以通过kid头参数获取。
JWS
证明
在上面的例子中，vc不包含id属性，因为 JWT 编码使用jti属性来表示唯一标识符。 sub属性编码了credentialSubject的id属性所代表的信息。nonce已被添加以阻止重放攻击。
nonce
在上述示例中，可验证展示使用了基于JWS数字签名的证明，相应的验证密钥可以通过kid标头参数获取。
在上面的例子中，vp不包含id属性，因为 JWT 编码使用jti属性来表示唯一标识符。 verifiableCredential包含一个字符串数组，其中包含使用JWT紧凑序列化格式的可验证凭证。添加了nonce（随机数）以防止重放攻击。
本规范利用关联数据，通过URL和JSON-LD等标准在Web上发布信息，以标识主体及其相关属性。 当信息以这种方式呈现时，其他相关信息可以很容易地被发现，新的信息也可以很容易地合并到现有的知识图谱中。 关联数据以一种去中心化的方式进行扩展，极大地降低了大规模集成的障碍。 本规范中的数据模型与数据完整性和相关的关联数据加密套件能够很好地协同工作，这些套件旨在保护本规范所描述的数据模型。
与JSON Web Token的使用不同，数据完整性证明无需任何额外的预处理或后处理。 数据完整性证明格式旨在简单、轻松地保护可验证凭证和可验证展示。保护可验证凭证或可验证展示就像将本规范中的有效示例传递给关联数据签名实现并生成数字签名一样简单。
有关不同语法格式（例如 JSON+JWT、JSON-LD+JWT 或 JSON-LD+LD-Proofs）质量的更多信息，请参阅《可验证凭证实施指南》[VC-IMP-GUIDE] 文档。
本节详细介绍了将可验证凭证数据模型部署到生产环境中的一般隐私考量和具体隐私影响。
务必认识到，隐私范围涵盖从匿名到强身份识别的各个层面。根据用例的不同，人们对于愿意提供的信息以及可以从所提供信息中推断出的信息，其接受程度也各不相同。
例如，大多数人在购买酒类时可能希望保持匿名，因为监管检查仅仅基于一个人是否达到特定年龄。 相反，对于医生为病人开具的医疗处方，药房在配药时需要更严格地识别医务人员和病人。因此，没有一种适用于所有用例的隐私方法。隐私解决方案是特定于用例的。
即使是那些希望在购买酒类时保持匿名的人，可能仍然需要提供照片身份证明，以便让商家获得适当的保证。 商家可能不需要知道你的姓名或其他详细信息（除了你超过特定年龄），但在许多情况下，仅仅证明年龄可能仍然不足以满足法规要求。
可验证凭证数据模型致力于支持全方位的隐私需求，并且不对任何特定交易的匿名程度采取既定的立场。以下部分为希望避免特定隐私敌对场景的实施者提供指导。
存储在可验证凭证的credential.credentialSubject字段中的数据，在与验证者共享时容易遭受隐私侵犯。 个人身份数据，例如政府签发的身份证件、收货地址和全名，很容易被用来确定、跟踪和关联一个实体。 即使是看似非个人身份的信息，例如出生日期和邮政编码的组合，也具有非常强大的关联和去匿名化能力。
credential.credentialSubject
强烈建议实施者在持有者共享此类特征的数据时发出警告。 强烈建议签发者尽可能提供保护隐私的可验证凭证。例如，当验证者想要确定一个实体是否超过18岁时，签发ageOver可验证凭证而不是出生日期可验证凭证。
ageOver
由于可验证凭证通常包含个人身份信息 (PII)，因此强烈建议实施者在存储和传输可验证凭证时使用保护数据不被未授权访问的机制。 可以考虑的机制包括传输层安全 (TLS) 或其他在传输过程中加密数据的方法，以及在静态存储时加密或数据访问控制机制来保护可验证凭证中的数据。
可验证凭证的主体是通过credential.credentialSubject.id字段进行标识的。用于标识主体的标识符如果长期存在或跨多个网络域名使用，则会增加关联风险。
credential.credentialSubject.id
类似地，公开凭证标识符（credential.id）会导致多个验证者或签发者和验证者合谋关联持有者的情况。如果持有者希望减少关联，他们应该使用允许在可验证展示期间隐藏标识符的可验证凭证方案。 此类方案期望持有者生成标识符，甚至可能允许对签发者隐藏标识符，同时仍然将标识符嵌入并签名到可验证凭证中。
credential.id
如果在可验证凭证系统中需要强大的反关联特性，强烈建议标识符满足以下条件之一：
可验证凭证的内容通过credential.proof字段进行安全保护。 当字段中的属性值在多个会话或域中重复使用且保持不变时，会增加关联性分析的风险。 例如verificationMethod、created、proofPurpose和jws字段。
credential.proof
verificationMethod
created
proofPurpose
jws
如果需要强大的反关联性，建议每次都使用第三方双向签名、零知识证明或群签名等技术重新生成签名值和元数据。
即使使用反关联签名，可验证凭证中也可能包含信息，这些信息会削弱所用密码学的反关联性。
可验证凭证可能包含长期标识符，这些标识符可用于关联个人身份。 这类标识符包括主体标识符、电子邮件地址、政府签发的标识符、组织签发的标识符、地址、医疗健康信息、可验证凭证特定的 JSON-LD 上下文，以及许多其他类型的长期标识符。
为持有者提供软件的组织应努力识别可验证凭证中包含的可能用于关联个人身份信息的字段，并在共享此类信息时向持有者发出警告。
可验证凭证存在一些外部机制，可以用来追踪和关联互联网和万维网上的个人身份。这些机制包括互联网协议 (IP) 地址追踪、网页浏览器指纹识别、永久性 Cookie、广告网络追踪器、移动网络位置信息以及应用程序内全球定位系统 (GPS) API。 使用可验证凭证并不能阻止这些追踪技术的使用。此外，当这些技术与可验证凭证结合使用时，可能会发现新的可关联信息。例如，生日与 GPS 位置信息结合起来，可以强有力地关联个人在多个网站上的活动。
建议尊重隐私的系统在使用可验证凭证时，应阻止使用这些追踪技术。在某些情况下，可能需要在代表持有者传输可验证凭证的设备上禁用追踪技术。
为了使可验证凭证的接收者能够在各种情况下使用它们，而不会泄露超出交易所需范围的个人身份信息 (PII)，签发者应考虑将凭证中发布的信息限制为预期用途所需的最小集合。 避免在凭证中包含 PII 的一种方法是使用抽象属性，这种属性可以满足验证者的需求，而无需提供关于主体的具体信息。
例如，本文档使用ageOver属性而不是具体的出生日期，因为后者构成了更强的 PII。 如果特定市场的零售商通常要求购买者达到特定年龄，则在该市场中受信任的签发者可以选择提供声称主体已满足该要求的可验证凭证，而不是提供包含特定出生日期声明的可验证凭证。这使得个人客户能够在不泄露特定 PII 的情况下进行购买。
当在一个情境下披露的信息泄露到另一个情境时，就会发生隐私侵犯。防止此类侵犯的公认最佳实践是将请求和接收的信息限制在绝对必要的最低限度。 这种数据最小化方法已在多个司法管辖区的法规中强制要求，包括美国的《健康保险流通与责任法案》(HIPAA) 和欧盟的《通用数据保护条例》(GDPR)。
对于可验证凭证，签发者的数据最小化意味着将可验证凭证的内容限制在潜在验证者预期用途所需的最低限度。对于验证者，数据最小化意味着限制访问服务时请求或要求的信息范围。
例如，包含驾驶员身份证号码、身高、体重、生日和家庭住址的驾驶执照就是一个包含的信息超出确定该人是否超过特定年龄所需信息的凭证。
签发者最好将信息原子化或使用允许选择性披露的签名方案。例如，驾驶执照的签发者可以签发包含驾驶执照上所有属性的可验证凭证，以及一组每个可验证凭证仅包含单个属性（例如，一个人的生日）的可验证凭证。 它还可以发布更抽象的可验证凭证（例如，仅包含ageOver属性的可验证凭证）。一种可能的改进是签发者提供安全的 HTTP 端点，用于检索一次性持有者凭证，以促进可验证凭证的匿名使用。 如果实施者认为这不切实际或不安全，则应考虑使用选择性披露方案，以消除在证明时对签发者的依赖，并降低签发者的时序关联风险。
强烈建议验证者仅请求特定交易发生绝对必要的信息。这至少有两个重要原因：
虽然可以践行最小披露原则，但在单个会话或多个会话期间，对于特定用例，可能无法避免对个人进行强身份识别。本文档的作者无法准确说明在现实场景中满足这一原则的难度。
持有者凭证是一种增强隐私的信息载体，例如音乐会门票，它赋予持有者获得特定资源的权利，而无需透露持有者的敏感信息。 持有者凭证通常用于低风险场景，在这些场景中，共享凭证并不会引发担忧，也不会造成重大的经济或声誉损失。
可验证凭证可以通过不指定主体标识符来实现持有者凭证的功能，该标识符通常使用嵌套在credentialSubject属性中的id属性来表示。例如，以下可验证凭证就是一个持有者凭证：
虽然持有者凭证可以增强隐私，但其设计必须谨慎，以免意外泄露超出持有者预期之外的信息。 例如，在多个站点重复使用相同的持有者凭证，可能导致这些站点合谋，对持有者进行过度跟踪或关联。 同样，看似非身份识别信息（例如出生日期和邮政编码），如果在同一持有者凭证或会话中同时使用，也可用于统计识别个人身份。
持有者凭证的签发者应确保持有者凭证提供的隐私增强优势能够：
如果签发或请求的持有者凭证包含敏感信息，或者在一次或多次会话中组合两个或多个持有者凭证存在关联风险，软件应向持有者发出警告。 虽然不可能检测到所有关联风险，但其中一些风险无疑是可以被察觉的。
验证者不应请求可能用于过度关联持有者的持有者凭证。
在处理可验证凭证时，验证者应执行A. 验证中列出的许多检查，包括验证以及各种特定的业务流程检查。有效性检查可能包括检查：
执行这些检查的过程可能会导致信息泄露，从而侵犯持有者的隐私。 例如，像检查撤销列表这样简单的操作就可以通知签发者某个特定企业可能正在与持有者进行交互。这可能使签发者能够在持有者不知情的情况下合谋并关联个人信息。
强烈建议签发者不要在核验过程中使用可能导致隐私泄露的机制，例如针对每个凭证都唯一的凭证撤销列表。 为持有者提供软件的组织应警告凭证中包含的信息是否可能在验证过程中导致隐私泄露。验证者应考虑拒绝那些会侵犯隐私或导致不良隐私行为的凭证。
当持有者从签发者处收到可验证凭证后，该可验证凭证需要存储在某个地方（例如，凭证存储库）。持有者需要注意的是，可验证凭证中的信息具有敏感性和高度个性化特征，使其成为数据挖掘的高价值目标。 一些宣称提供免费可验证凭证存储的服务，实际上可能是在挖掘个人数据并将其出售给希望构建个人和组织个性化档案的机构。
持有者需要了解其凭证存储库的服务条款，特别是针对将可验证凭证存储在该服务提供商处的用户所提供的关联和数据挖掘保护措施。
一些有效缓解数据挖掘和画像的方法包括：
即使信息来自不同的渠道，掌握同一主体两条信息也几乎总会比这两条信息简单相加所能揭示的更多。可验证凭证的聚合存在隐私风险，生态系统中的所有参与者都需要意识到数据聚合的风险。
例如，如果在多次会话中提供了两个持有者凭证，一个用于电子邮件地址，另一个表明持有者年龄超过 21 岁，那么信息验证者现在就拥有了该个人的唯一标识符以及年龄相关信息。 这样一来，创建和构建持有者档案就变得轻而易举，随着时间的推移，越来越多的信息会被泄露。凭证聚合也可以通过多个站点相互合谋来执行，从而导致侵犯隐私。
从技术的角度来看，防止信息聚合是一个非常难以解决的隐私问题。 虽然新的密码学技术，如零知识证明，被提议作为解决聚合和关联问题的方案，但长期存在的标识符和浏览器跟踪技术的存在，即使是最现代的密码学技术也无法克服。
关联或聚合带来的隐私问题的解决方案往往不是技术性的，而是政策驱动的。因此，如果持有者不希望自己的信息被聚合，他们必须在他们传输的可验证展示中表达这一点。
尽管已尽最大努力确保隐私，但实际使用可验证凭证仍可能导致去匿名化和隐私泄露。当出现以下情况时，可能会发生这种关联：
在某种程度上，可以通过以下方式减轻这种去匿名化和隐私泄露：
可以理解的是，这些缓解技术并不总是切实可行的，甚至与必要的用途不兼容。有时关联是必需的。
例如，在某些处方药监控程序中，使用监控是一项要求。执法机构需要能够确认个人没有欺骗系统以获取多种受管制物质的处方。这种关联使用的法定或监管需求凌驾于个人隐私问题之上。
可验证凭证也将用于有意地跨服务关联个人，例如，当使用通用角色登录多个服务时，所有这些服务上的所有活动都会有意地链接到同一个人。只要每个服务都以预期的方式使用关联，这就不是隐私问题。
当凭证的提交产生意外或非预期的关联时，就会出现凭证使用的隐私风险。
当持有者选择与验证者分享信息时，验证者有可能出于恶意行为并请求可能对持有者造成损害的信息。例如，验证者可能会索要银行账号，然后将其与其他信息一起用于欺诈持有者或银行。
签发者应努力将尽可能多的信息进行令牌化处理，以便在持有者意外地将凭证传输给错误的验证者时，不至于造成灾难性的后果。
例如，与其为了查询个人银行余额而直接提供银行账号，不如提供一个令牌，使验证者能够查询余额是否高于特定金额。在这种情况下，银行可以向持有者签发包含余额查询令牌的可验证凭证。 然后，持有者将可验证凭证包含在可验证展示中，并使用数字签名将令牌绑定到征信机构。验证者随后可以用其数字签名封装可验证展示，并将其交还给签发者以动态查询账户余额。
使用这种方法，即使持有者与错误方共享了账户余额令牌，攻击者也无法获取银行账号，也无法获知账户的确切金额。并且，鉴于会签的有效期，攻击者对令牌的访问权限不会超过几分钟。
正如7.13 使用模式中详细描述的那样，使用模式可以关联到某些类型的行为。 当持有者在签发者不知情的情况下使用可验证凭证时，这种关联性会被部分削弱。然而，签发者可以通过缩短可验证凭证的有效期并使其自动续期来克服这种保护措施。
例如，一个ageOver的可验证凭证可以用来进入酒吧。如果签发者签发的此类可验证凭证有效期非常短，并且具有自动续期机制，那么签发者就有可能关联持有者的行为，从而对持有者产生负面影响。
为持有者提供软件的组织应该警告他们，如果他们反复使用有效期很短的凭证，可能会导致行为关联。签发者应避免以能够关联使用模式的方式签发凭证。
一个理想的、尊重隐私的系统应当只要求持有者披露与验证者交互的必要信息。验证者随后会记录披露要求已得到满足，并忘记任何已披露的敏感信息。在许多情况下，诸如监管负担等相互竞争的优先事项会阻碍这种理想系统的实施。 在其他情况下，长期存在的标识符会妨碍单次使用。然而，任何可验证凭证生态系统的设计都应尽可能地尊重隐私，尽可能优先考虑使用一次性可验证凭证。
使用一次性可验证凭证具有诸多益处。首先，验证者可以确信可验证凭证中的数据是最新的。其次，持有者知道，如果可验证凭证中没有长期存在的标识符，那么该可验证凭证本身就不能用于在线跟踪或关联他们。 最后，攻击者也无从下手，使整个生态系统更加安全可靠。
理想情况下，私密浏览模式不会泄露任何个人身份信息 (PII)。由于许多凭证都包含 PII，因此，为持有者提供软件的组织应提醒他们，如果希望在私密浏览模式下使用凭证和展示，则有可能泄露这些信息。 鉴于每个浏览器厂商对私密浏览的处理方式不同，并且某些浏览器可能根本不具备此功能，因此，开发者务必了解这些差异并相应地调整方案。
可验证凭证高度依赖于对签发者的信任，这一点怎么强调都不为过。持有者能够利用各种隐私保护措施的程度，往往很大程度上取决于签发者对这些功能的支持力度。 在许多情况下，诸如零知识证明、数据最小化技术、持有者凭证、抽象声明以及防签名关联等隐私保护措施，都需要签发者积极支持并将它们融入到其签发的可验证凭证之中。
还需注意的是，除了依赖签发者参与提供有助于保护持有者和主体隐私的可验证凭证功能外，持有者还依赖于签发者不会故意破坏隐私保护。例如，签发者可以使用一种防止签名关联的签名方案来签发可验证凭证。 这将保护持有者在与验证者共享凭证时，不会因签名值而被关联起来。 然而，如果签发者为每个签发的凭证都创建一个唯一的密钥，那么签发者就有可能跟踪凭证的展示情况，即使验证者无法做到这一点。
在处理本规范所述数据时，签发者、持有者和验证者应注意诸多安全问题。忽略或不理解本节内容的含义可能导致安全漏洞。
虽然本节试图强调广泛的安全注意事项，但它并非详尽无遗。强烈建议实施者在使用本规范概述的技术实施关键任务系统时，寻求安全和密码学专家的建议。
（本节为非规范性内容）
本规范中描述的数据模型的某些方面可以通过密码学技术进行保护。开发者务必了解用于创建和处理凭证及展示的密码套件和库。密码系统的实施和审计通常需要深厚的专业知识。此外，有效的红队测试也有助于消除安全审查中的主观偏差。
密码套件和库都有其生命周期，新的攻击手段和技术进步最终会使其过时。生产级系统需要考虑到这一点，并确保能够轻松、主动地升级过时或失效的密码套件和库，同时具备使现有凭证失效和替换的机制。定期监控对于保障凭证处理系统的长期有效性至关重要。
本节为非规范性内容。
可验证凭证通常包含指向凭证本身以外数据的 URL。链接到可验证凭证外部的内容，如图像、JSON-LD 上下文和其他机器可读数据，通常无法防止篡改，因为这些数据位于可验证凭证的保护范围之外。例如，以下高亮显示的链接没有受到内容完整性保护，但或许应该受到保护：
尽管本规范没有推荐任何特定的内容完整性保护措施，但建议希望确保内容链接得到完整性保护的文档作者使用强制执行内容完整性的 URL 方案。[HASHLINK]规范和[IPFS]就是两个这样的方案。下面的示例对前面的示例进行了转换，并使用[HASHLINK]规范为 JSON-LD 上下文添加了内容完整性保护，并使用[IPFS]链接为图像添加了内容完整性保护。
以上 JSON-LD 上下文是否需要保护存在争议，因为生产环境的实现预计会附带重要JSON-LD 上下文的静态副本。
虽然上述示例是一种实现内容完整性保护的方法，但某些应用场景可能需要其他解决方案。实施者务须了解，如果链接到未受内容完整性保护的外部机器可读内容，可能会导致应用程序遭受攻击。
本规范允许生成不包含任何签名或证明的凭证。此类凭证通常适用于中间存储或自我声明的信息，类似于填写网页上的表单。实施者应注意，此类凭证无法验证，因为其作者身份未知或不可信。
验证者可能需要确保它是可验证展示的预期接收者，而不是中间人攻击的目标。诸如令牌绑定 [RFC8471] 之类的方法，它将可验证展示的请求与响应绑定在一起，可以保护协议的安全。任何不安全的协议都容易受到中间人攻击。
建议签发者将凭证中的信息原子化，或使用允许选择性披露的签名方案。在原子化的情况下，如果签发者没有安全地进行原子化，持有者可能会以签发者不期望的方式将不同的凭证绑定在一起。
例如，一所大学可能会向一个人签发两份可验证凭证，每份凭证包含两个属性，这两个属性必须结合在一起才能指定该人在特定“部门”中的“角色”，例如“计算机系”的“工作人员”或“经济学系”的“研究生”。如果将这些可验证凭证原子化，以便每个凭证只包含其中一个属性，则大学将向该人签发四份凭证，每份凭证包含以下名称之一：“工作人员”、“研究生”、“计算机系”和“经济学系”。然后，持有者可能会将“工作人员”和“经济学系”可验证凭证转移给验证者，这两个凭证加在一起将构成虚假声明。
当可验证凭证用于发布高动态信息时，实施者应确保适当地设置过期时间。如果过期时间超过可验证凭证的有效期限，则可能产生可利用的安全漏洞。如果过期时间短于可验证凭证所表达信息的有效期限，则会给持有者和验证者带来负担。因此，为可验证凭证设置与其用例和凭证中包含信息的预期生命周期相适应的有效期至关重要。
当可验证凭证存储在设备上，且该设备丢失或被盗时，攻击者有可能使用受害者的可验证凭证访问系统。缓解此类攻击的方法包括：
在处理本规范中描述的数据时，实施者应注意许多可访问性考量。与任何网络标准或协议的实施一样，忽视可访问性问题将导致很大一部分人群无法使用这些信息。遵循可访问性指南和标准（例如 [WCAG21]）至关重要，以确保所有能力水平的人都能使用这些数据。这在建立使用密码学的系统时尤为重要，因为这些系统历来对辅助技术造成了困扰。
本节详细介绍了使用此数据模型时需要考虑的总体无障碍因素。
目前使用的许多实体凭证，例如政府身份证，都存在较差的可访问性特征，包括但不限于：字体过小、依赖小型高分辨率图像，以及对视障人士缺乏便利设施。
在利用此数据模型创建可验证凭证时，建议数据模型设计者采用数据优先的方法。例如，在选择使用数据或图形图像来描述凭证时，设计者应该以机器可读的方式表达图像的每个元素，例如机构名称或专业凭证，而不是依赖观看者对图像的解读来传达此信息。数据优先方法更受青睐，因为它为构建针对不同能力人士的不同界面提供了基础要素。
建议开发者在发布符合本规范的数据时，注意一些国际化方面的考量。与任何网络标准或协议的实现一样，忽略国际化会导致数据难以跨越不同的语言和社会环境进行生成和使用，从而限制规范的适用性，并显著降低其作为标准的价值。
强烈建议开发者阅读 W3C 国际化行动发布的《网络上的字符串：语言和方向元数据》文档[STRING-META]，该文档详细阐述了提供可靠的文本元数据以支持国际化的必要性。若需了解国际化考量的最新信息，也建议开发者阅读《可验证凭证实施指南》 [VC-IMP-GUIDE] 文档。
本节概述了在使用此数据模型时需要考虑的一般国际化因素，旨在重点介绍《网络上的字符串：语言和方向元数据》文档 [STRING-META] 中开发者可能感兴趣的特定部分。
强烈建议数据发布者阅读《网络上的字符串：语言和方向元数据》文档 [STRING-META] 中关于跨语法表达的部分，以确保语言和基本方向信息的表达能够跨越多种表达语法，例如[JSON-LD]、[JSON] 和 CBOR [RFC7049]。
表示带有语言标签和可选的特定基准方向的文本字符串时，通常的设计模式是使用以下标记模板。
使用上述设计模式，以下示例在不指定文本方向的情况下，用英文表达了一本书的标题。
下一个示例采用了类似的标题，以阿拉伯语书写，其基本书写方向是从右到左。
以上文字如果没有明确的语言和方向指示，很有可能会被错误地渲染成从左到右的排列方式，因为很多系统会根据文本字符串的第一个字符来判断文本方向。
强烈建议使用 JSON-LD 的实施者扩展定义国际化属性的 JSON-LD 上下文，并利用 JSON-LD的作用域上下文特性，将 @value、@language 和 @direction 关键字分别简写为 value、lang和 dir。 以下示例代码片段展示了如何实现这一点。
当单个自然语言字符串中使用多种语言、书写方向和注释时，通常需要更复杂的机制。可以使用 HTML 等标记语言对包含多种语言和书写方向的文本进行编码。也可以使用 rdf:HTML数据类型在 JSON-LD 中准确编码此类值。
尽管可以将信息编码为 HTML，但强烈建议实施者避免这样做，原因如下：
如果实施者认为必须使用 HTML 或其他能够包含可执行脚本的标记语言来解决特定用例，建议他们分析攻击者将如何利用标记对标记使用者发起注入攻击，然后针对已识别的攻击部署缓解措施。
尽管本规范没有为可验证凭证或可验证展示的验证过程提供一致性标准，但读者可能仍然好奇验证者在验证过程中将如何使用此数据模型中的信息。本节摘录了工作组就验证者对本规范中数据字段的预期使用情况进行的一些讨论。
在持有者出示的可验证凭证中，每个 credentialSubject 的 id 属性所关联的值预期用于向验证者标识主体。如果持有者同时也是主体，并且验证者拥有与持有者相关的公钥元数据，那么验证者就可以对持有者进行身份验证。验证者可以使用可验证展示中包含的、由持有者生成的签名来进行身份验证。id 属性是可选的。验证者可以使用可验证凭证中的其他属性来唯一标识主体。
有关身份验证和WebAuthn如何与可验证凭证协同工作的信息，请参阅《可验证凭证实施指南》[VC-IMP-GUIDE]文档。
签发者属性的值预期用于识别一个验证者知晓并信任的签发实体。
与签发者属性相关的元数据预期可供验证者使用。例如，签发者可以发布包含其用于对其签发的可验证凭证进行数字签名的公钥的信息。这些元数据在检查可验证凭证的证明时非常重要。
签发日期预期在验证者的预期范围内。例如，验证者可以检查可验证凭证的颁发日期是否在未来。
用于证明可验证凭证或可验证展示中的信息未被篡改的加密机制称为证明。存在多种类型的加密证明，包括但不限于数字签名、零知识证明、工作量证明和权益证明。通常，在验证证明时，预期实现能够确保：
一些证明是数字签名。通常，在验证数字签名时，预期实现能够确保：
除了防篡改之外，数字签名还提供了许多其他并非显而易见的保护。例如，创建的链接数据签名属性会建立一个日期和时间，在此之前不应将凭证视为已验证。verificationMethod属性指定了例如可用于验证数字签名的公钥。解引用公钥URL会显示有关密钥控制者的信息，可以将其与凭证的签发者进行核对。 proofPurpose属性清楚地表达了证明的目的，并确保此信息受到签名的保护。证明通常附加到可验证展示以进行身份验证，并附加到可验证凭证作为声明的方法。
验证者预期 verifiable credential 的 expirationDate（有效期）字段值应在一个合理的范围内。例如，验证者可以检查可验证凭证的有效期是否已过期。
如果存在credentialStatus（凭证状态）属性可用，验证者预期将根据verifiable credential的credentialStatus类型定义以及验证者自身的状态评估标准，对可验证凭证的状态进行评估。例如，验证者可以确保可验证凭证的状态不是“已被签发者撤销”。
用途适用性是指verifiable credential中的自定义属性是否适合验证者的用途。例如，如果验证者需要确定主体是否年满21岁，他们可能依赖于特定的birthdate（出生日期）属性，或者更抽象的属性，例如ageOver（超过…岁）。
验证者信任签发者做出的声明。例如，一家特许经营的快餐店相信该特许经营总部的优惠券声明。除非持有者和验证者愿意承担忽略策略的责任，否则他们应遵守签发者在verifiable credential中表达的策略信息。
基础上下文位于 https://www.w3.org/2018/credentials/v1，其 SHA-256 摘要值为ab4ddd9a531758807a79a5b450510d61ae8d147eab966cc9a200c07095b0cdcc，可以用于实现本地缓存副本。为方便起见，本节还提供了该基础上下文。
可验证凭证和可验证展示数据模型利用了多种底层技术，包括 [JSON-LD] 和[JSON-SCHEMA-2018]。本节将比较 @context、type 和 credentialSchema 属性，并涵盖一些可以更具体地使用数据模型这些功能的用例。
type 属性用于唯一标识其出现的可验证凭证的类型，即指示可验证凭证包含哪些声明集合。此属性及其值集合中的 VerifiableCredential 值是必需的。虽然建议包含一个描述此可验证凭证唯一子类型的值，但允许在数组中省略或包含其他类型值。许多验证者会请求特定子类型的可验证凭证，因此省略子类型值可能会使验证者更难以告知持有者他们需要哪种可验证凭证。当可验证凭证具有多个子类型时，将所有子类型都列在 type 属性中是合理的。虽然在[JSON] 和 [JSON-LD] 表示形式中语义相同，但在可验证凭证的 [JSON-LD] 表示形式中使用type 属性能够比相同凭证的 [JSON] 表示形式更好地强制执行可验证凭证的语义，因为机器能够检查语义。使用 [JSON-LD]，该技术不仅描述了声明集的分类，还传达了图中属性子图的结构和语义。在 [JSON-LD] 中，这表示图中节点的类型，这就是为什么可验证凭证的一些[JSON-LD] 表示形式会在可验证凭证中的许多对象上使用 type 属性的原因。
从 [JSON-LD] 的角度来看，@context 属性的主要目的是以机器可读的方式传达可验证凭证中数据的含义和术语定义。在编码纯 [JSON] 表示形式时，@context 属性仍然是必需的，并为全局语义提供了一些基本支持。@context 属性用于将可验证凭证和可验证展示中属性的全局唯一 URI 映射到简短的别名，使 [JSON] 和 [JSON-LD] 表示形式更易于人类阅读。从 [JSON-LD] 的角度来看，这种映射还允许通过增强可验证凭证或可验证展示中的数据与更大的机器可读数据图的关系，将凭证中的数据建模在机器可读数据网络中。这对于告诉机器如何在各方无法协调的生态系统中将数据的含义与其他数据相关联非常有用。此属性是必需的，其集合中的第一个值是 https://www.w3.org/2018/credentials/v1。
由于 @context 属性用于将数据映射到图数据模型，并且 [JSON-LD] 中的 type 属性用于描述图中的节点，因此在组合使用这两个属性时，type 属性变得更加重要。例如，如果未使用 [JSON-LD] 在解析的 @context 资源中包含 type 属性，则可能导致在生成和使用可验证凭证期间删除声明和/或不再保护其完整性。或者，它可能导致在生成或使用可验证凭证期间引发错误。这将取决于实现的设计选择，并且当前的实现中使用了这两种路径，因此在使用可验证凭证或可验证展示的 [JSON-LD] 表示形式时，务必注意这些属性。
credentialSchema 属性的主要目的是定义可验证凭证的结构以及出现的每个属性值的数据类型。credentialSchema 对于定义可验证凭证中一组声明的内容和结构很有用，而可验证凭证中的 [JSON-LD] 和 @context 最好仅用于传达数据的语义和术语定义，他们也可以用于定义可验证凭证的结构。
虽然可以使用一些 [JSON-LD] 功能来暗示可验证凭证的内容，但通常不建议使用 @context来约束数据模型的数据类型。例如，“@type”：“@json”对于保持语义开放且未严格定义很有用。如果实现者希望约束凭证中声明的数据类型，这可能会很危险，不建议这样做。
当 credentialSchema 和 @context 属性组合使用时，生产者和消费者都可以对可验证凭证和可验证展示的预期内容和数据类型更有信心。
本节阐述主体与持有者之间可能存在的关系，以及可验证凭证数据模型如何表达这些关系。下图展示了这些关系，后续章节将分别阐述数据模型如何处理每种关系。
最常见的关系是主体同时也是持有者。在这种情况下，如果可验证展示（由持有者完成数字签名，且其中包含的所有可验证凭证所涉及的主体都可被识别为与该持有者为同一实体，那么验证者就能轻松推断出主体即持有者。
如果仅允许credentialSubject将可验证凭证纳入可验证呈现，那么颁发者可以在该可验证凭证中加入nonTransferable属性，具体如下文所述。
nonTransferable属性表明，可验证凭证只能封装到由credentialsubject签发证明的可验证展示中。如果一个可验证展示包含一个带有nonTransferable属性的可验证凭证，但其证明创建者并非credentialsubject，则该可验证展示无效。
在本例中，credentialSubject属性可能包含多个属性，每个属性都提供了主体描述的一个方面，这些属性组合在一起可以明确地标识主体。某些用例可能根本不需要标识持有者，例如检查医生（主体）是否获得了委员会认证。其他用例可能要求验证者使用带外知识来确定主体和持有者之间的关系。
上述例子仅凭借姓名、地址和出生日期便唯一确定了该主体的身份。
通常情况下，可验证凭证由主体呈现给验证者。然而，在某些情况下，主体可能需要将可验证凭证的全部或部分传递给另一个持有者。例如，如果患者（主体）病情严重，无法将处方（可验证凭证）带到药剂师（验证者）那里，朋友可以代为取药。
数据模型允许主体签发新的可验证凭证并将其交给新的持有者，然后新的持有者可以将两个可验证凭证都呈现给验证者。但是，第二个可验证凭证的内容可能特定于应用程序，因此本规范无法标准化第二个可验证凭证的内容。尽管如此，附录 C.5 主体将可验证凭证传递给他人 中提供了一个非规范性示例。
可验证凭证数据模型至少通过以下方式支持持有者代表主体行事：
上述机制描述了持有者与主体之间的关系，并帮助验证者确定该关系是否足以表达给定的用例。
签发者或验证者用来验证主体与持有者之间关系的额外机制不在本规范的范围内。
在上述例子中，签发者阐明了孩子与父母之间的关系，使得验证者更有可能接受由孩子或父母提供的凭证。
在上述例子中，签发者在一个单独的凭证中表达了孩子和父母之间的关系，这样一来，无论这个单独的凭证是否与孩子的任意凭证一起出示，验证者都很可能会接受孩子的任意凭证。
在上述例子中，孩子在一个单独的凭证中表达了孩子与父母之间的关系，这样一来，如果提供了上述凭证，验证者很可能会接受孩子出示的任何凭证。
同样，上述例子中描述的策略可以用于许多其他类型的用例，包括授权委托、宠物所有权和病人处方取药等。
当主体将可验证凭证传递给另一个持有者时，主体可以向该持有者签发一个新的可验证凭证，其中：
持有者现在可以创建一个包含这两个可验证凭证的可验证展示，以便验证者可以验证主体是否将原始可验证凭证给予了该持有者。
当签发者希望授权持有者持有描述一个非持有者本人的凭证，且持有者与凭证主体之间不存在已知关系时，签发者可以将持有者与自身的关系写入凭证主体的凭证中。
可验证凭证并非授权框架，因此授权不在本规范的讨论范围内。然而，可以理解的是，可验证凭证很可能被用于构建授权和委托系统。以下是一种可能适用于某些用例的方法。
可验证凭证数据模型目前不支持上述任一场景。如何支持这些场景有待进一步研究。
本节将提交给互联网工程指导小组(IESG)审查、批准，并向IANA的“JSON Web Token声明注册表”进行注册。
本节包含自v1.0版本规范发布为 W3C 推荐标准以来所做的主要变更。
自推荐标准发布以来的变更：
工作组感谢以下个人，不仅感谢他们对本文档内容的贡献，还感谢他们在标准社区中的辛勤工作，这些工作推动了众多不同意见之间的变革、讨论和共识：Matt Stone、Gregg Kellogg、Ted Thibodeau Jr、Oliver Terbu、Joe Andrieu、David I. Lehn、Matthew Collier 和 Adrian Gropper。
本规范的工作得到了由Christopher Allen、Shannon Appelcline、Kiara Robles、Brian Weller、Betty Dhamers、Kaliya Young、Manu Sporny、Drummond Reed、Joe Andrieu、Heather Vescent、Kim Hamilton Duffy、Samantha Chase 和 Andrew Hughes 推动的 “重启信任网络” 社区的支持。由 Phil Windley、Kaliya Young、Doc Searls 和 Heidi Nobantu Saul 推动的互联网身份研讨会的参与者也通过旨在教育、辩论和改进本规范的众多工作会议支持了这项工作的完善。
工作组还感谢我们的主席 Dan Burnett、Matt Stone、Brent Zundel 和 Wayne Chang，以及我们的 W3C 员工联系人 Kazuyuki Ashimura 和 Ivan Herman，感谢他们在 W3C 标准化过程中对小组的专业管理和坚定指导。
本规范的部分工作由美国国土安全部科学技术局根据合同HSHQDC-17-C-00019资助。本规范的内容不一定反映美国政府的立场或政策，也不应推断出任何官方认可。
工作组感谢以下个人审查并提供有关规范的反馈（按字母顺序排列）：
Christopher Allen、David Ammouial、Joe Andrieu、Bohdan Andriyiv、Ganesh Annan、Kazuyuki Ashimura、Tim Bouma、Pelle Braendgaard、Dan Brickley、Allen Brown、Jeff Burdges、Daniel Burnett、ckenndy422、David Chadwick、Chaoxinhu、Kim (Hamilton) Duffy、Lautaro Dragan、enuoCM、Ken Ebert、Eric Elliott、William Entriken、David Ezell、Nathan George、Reto Gmür、Ryan Grant、glauserr、Adrian Gropper、Joel Gustafson、Amy Guy、Lovesh Harchandani、Daniel Hardman、Dominique Hazael-Massieux、Jonathan Holt、David Hyland-Wood、Iso5786、Renato Iannella、Richard Ishida、Ian Jacobs、Anil John、Tom Jones、Rieks Joosten、Gregg Kellogg、Kevin、Eric Korb、David I. Lehn、Michael Lodder、Dave Longley、Christian Lundkvist、Jim Masloski、Pat McBennett、Adam C. Migus、Liam Missin、Alexander Mühle、Anthony Nadalin、Clare Nelson、Mircea Nistor、Grant Noble、Darrell O'Donnell、Nate Otto、Matt Peterson、Addison Phillips、Eric Prud'hommeaux、Liam Quin、Rajesh Rathnam、Drummond Reed、Yancy Ribbens、Justin Richer、Evstifeev Roman、RorschachRev、Steven Rowat、Pete Rowley、Markus Sabadello、Kristijan Sedlak、Tzviya Seigman、Reza Soltani、Manu Sporny、Orie Steele、Matt Stone、Oliver Terbu、Ted Thibodeau Jr、John Tibbetts、Mike Varley、Richard Varn、Heather Vescent、Christopher Lemmer Webber、Benjamin Young、Kaliya Young、Dmitri Zagidulin 和 Brent Zundel。
↑
Referenced in:
